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There  is  no  question  that  Department  of  Defense 
and  chairman  of  the  Joint  Chiefs  of  Staff  directives 
have  increased  the  development  of  operational 
and  systems  architectures.  The  DoD  Architectural 
Framework  (DoDAF)  and  its  associated  governing 
publications  have  provided  considerable  information  and 
examples  covering  DoD  architecture  processes  and  prod¬ 
ucts  for  those  engaged  in  requirements  and  architecture 
development.  But  even  though  the  guidance  is  good,  there 
need  to  be  more  general  heuristics  to  help  guide  those 
involved  in  this  growth  industry.  Based  on  recent  experi¬ 
ences  with  joint  architecture  development,  we  propose 
some  general  heuristics  covering  the  following:  the  ar¬ 
chitecture  team;  common  lexicon;  process  ownership; 
appropriate  abstraction;  organizational  bias;  level-of-war 
bias;  and  hollow-transfer  activities. 

The  Architecture  Team 

The  majority  of  architecture  producers  in  the  DoD  are  ei¬ 
ther  government  civilians  or  contractors.  Borrowing  an 
Army  slogan,  they  are  also  often  an  army  of  one.  Their 
levels  of  formal  architecture  education  and  training  usu¬ 
ally  vary,  and  their  domain  knowledge  of  the  area  being 
modeled  is  usually  low.  Ultimately,  lack  of  knowledge  in 
the  domain  equals  architecture  pain.  If  at  all  possible, 
members  of  an  architecture  team  should  not  only  un¬ 
derstand  architecture  design  well,  but  also  have  real-life 
experience  in  the  domain  being  modeled.  Unfortunately, 
because  of  personnel  and  budget  constraints,  that  may 
not  be  possible.  Therefore,  how  well  an  architect  or  an 
architecture  team  develops  an  extended  team  of  subject 
matter  experts  and  contacts  is  critical  to  developing  a  use¬ 
ful  architecture.  If  the  architecting  team  makes  little  to  no 
effort  to  seek  out  domain  expertise  when  they  do  not 
have  it,  or  if  they  reference  only  governing  publications 
and  briefs,  the  models  produced  will  be  poor,  and  the  ar¬ 
chitecture  will  most  likely  not  provide  the  benefits  sought. 

Common  Lexicon 

The  lack  of  common  terminology  is  quickly  apparent  in 
any  joint  endeavor.  There  are  still  a  number  of  terminol¬ 
ogy  differences  between  the  Services  that  often  confuse 
those  outlining  operational  architecture  inputs,  controls, 
and  outputs.  An  example  is  the  terms  that  different  Ser¬ 
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vices  use  for  a  pre-execution  practice.  The  Army  and 
Marines  often  use  the  term  “rock  drill,”  while  the  Air  Force 
primarily  uses  the  term  “rehearsal.”  Both  mean  roughly 
the  same  thing,  but  to  Air  Force  personnel  not  familiar 
with  Army  terminology,  discussion  of  a  “rock  drill”  can 
be  confusing.  Therefore,  use  the  joint  dictionary  in  order 
to  have  a  joint  vocabulary.  Any  time  definitions  are  needed, 
use  joint  standards  and  sources,  such  as  Joint  Publication 
1  -02,  Department  of  Defense  Dictionary  of  Military  and  As¬ 
sociated  Terms.  If  those  do  not  work,  reference  multi-Ser- 
vice  publications.  If  there  is  no  resolution,  all  the  applic¬ 
able  definitions  should  be  provided,  with  indication  that 
they  mean  the  same  thing. 

Process  Ownership 

Determining  who  owns  the  process  in  joint  activities  has 
long  been  a  part  of  doctrinal  debates  and  continues  to  in¬ 
fluence  how  the  Services  integrate  and  interoperate.  Even 
though  one  Service  may  be  the  lead  for  certain  types  of 
operations  (for  example,  the  Air  Force  for  air  superiority 
or  the  Army  for  the  land  campaign),  other  Services  can 
execute  the  same  or  very  similar  processes  within  the 
same  domain.  The  Navy  can  conduct  air  superiority  mis¬ 
sions  and  the  Marines  can  conduct  land  operations.  With 
multiple  Services  and  commands  involved,  there  are  mul¬ 
tiple  and  overlapping  guidances,  terminologies,  and  tech¬ 
niques.  Overlapping  guidance  adds  to  the  confusion  when 
attempting  to  standardize  common  processes,  especially 
with  operational  activities  in  joint  enterprise  architecture. 
Ideally,  joint  architectures  need  to  have  buy-in  by  all  the 
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FIGURE  1 .  Activity-Based  Node  Tree 


major  stakeholders.  Unfortunately, 
this  is  not  always  the  case.  There¬ 
fore,  when  defining  a  joint  process 
stalls,  there  needs  to  be  a  process 
owner  to  make  firm  calls  so  the  ar¬ 
chitecture  moves  forward,  a  base 
standard  is  set,  and  interoperabil¬ 
ity  is  achieved  when  needed.  This 
owner  or  lead  agent  must  benevo¬ 
lently  determine  what  the  core  ac¬ 
tivities  in  an  operational  architec¬ 
ture  will  be  and  how  to  overcome 
community  or  stakeholder  differences. 

Appropriate  Abstraction 

One  of  the  hardest  things  to  do  when  developing  archi¬ 
tecture  is  to  define  the  level  of  abstraction.  How  deep  in 
the  weeds  does  the  architect  or  architecture  team  go? 
DoDAF  states  that  the  “degree  of  granularity  should  be 
driven  by  the  type  of  analysis  or  assessments  that  are  of 
interest.”  But  finding  the  right  level  of  granularity  can  be 
very  hard,  and  it  can  take  multiple  design  iterations.  If 
models  are  made  at  a  high  level  only,  the  architect  risks 
developing  architecture  that  can  be  easily  briefed  to  top 
leaders  and  fills  program  requirements,  but  does  not  an¬ 
swer  critical  questions  for  field  operators  and  true  stake¬ 
holders.  This  becomes  a  critical  tradeoff  in  joint  enter¬ 
prise  architecture  that  should  not  be  quickly  overlooked. 
The  right  level  of  abstraction  highlights  commonality  and 
critical  differences  across  Services  and  commands.  At  the 
same  time,  it  also  addresses  operational  processes  in 
enough  detail  to  allow  informed  decisions  for  the  ques¬ 
tions  being  asked.  If  the  right  level  of  abstraction  is  not 
chosen,  the  model  is  useless  to  those  who  need  it  the 
most.  Therefore,  abstract  too  high — the  models  can  lie; 
abstract  too  low — one  gets  lost  in  the  flow.  Finding  the 
right  level  of  abstraction  is  critical  in  ensuring  the  archi¬ 
tecture  can  be  communicated  effectively  and  still  be  use¬ 
ful  for  its  intended  purpose. 

Organizational  Bias 

Within  the  DoD,  almost  everything  revolves  around  the 
organization.  This  includes  funding,  identity,  deployments, 
and  other  activities.  Existing  regulations  tend  to  focus  on 
job  titles,  roles,  and  responsibilities — not  on  key  processes. 
When  transformation  is  conducted,  the  first  questions 
asked  usually  concern  where  people  will  be  assigned  and 
what  organization  charts  will  look  like.  It  has  often  been 
said  that  the  default  method  to  solve  a  government  prob¬ 
lem  is  to  generate  a  new  organization.  This  mindset — 
thinking  in  terms  of  organization  and  jobs  first — is  what 
we  call  “organizational  bias.”  DoDAF  operational  views 
are  supposed  to  focus  on  activities  and  functions,  not  on 
organizations.  As  enterprise  architects  look  across  a  com¬ 
plex  environment  like  the  DoD  system  of  systems,  they 
usually  find  it  is  easier  to  identify  organizations  and  not 
underlying  activities.  DoD  architects  must  realize  that 


many  of  the  publications  they  reference  and  the  subject 
matter  experts  with  whom  they  consult  will  tend  to  have 
this  bias  and  will  not  focus  on  core  processes.  Unfiltered 
organizational  bias  can  result  in  operational  activities  that 
are  stove-piped  and  inefficient.  This  is  easily  seen  when 
examining  an  activity  node  tree  (OV-5)  that  has  been  heav¬ 
ily  influenced  by  organizational  structure.  The  organiza¬ 
tional  bias  is  often  depicted  as  repeated  boxes  that  iden¬ 
tify  the  same  or  similar  activity  in  different  branches  on 
the  tree. 

To  illustrate,  consider  a  notional  example  in  which  the  ar¬ 
chitecture  team  is  modeling  the  operational  activities  of 
an  Air  Force  special  operations  organization.  Assume  the 
organization  has  three  main  functions:  provide  force  ap¬ 
plication  (direct  attack  on  adversary  forces);  provide  mo¬ 
bility  (infiltration  and  exfiltration);  and  perform  psycho¬ 
logical  operations  (dropping  leaflets  and  broadcasting 
television  or  radio  programs).  Each  of  these  functions  is 
performed  using  different  assets  (personnel  and  aircraft) 
but  involves  similar  activities,  such  as  “pre-mission  plan¬ 
ning,”  “launch  aircraft,”  “conduct  en-route  operations,” 
“accomplish  recovery,”  and  “conduct  post-mission  de¬ 
briefs.” 

An  architecture  model — and  more  important,  a  mind¬ 
set — that  relies  too  much  on  organizational  form  could 
very  easily  result  in  an  activity  node  tree  with  major 
branches  built  around  each  mission  function  and  with 
duplicate  lower-level  branches.  These  lower-level  branches 
may  result  in  development  of  numerous  tools  or  systems, 
all  essentially  aimed  at  providing  the  same  capability.  For 
example,  three  different  (stove-piped)  systems  could  very 
well  be  developed  to  facilitate  “conduct  en-route  opera¬ 
tions”  for  the  force  application,  provide  mobility,  and  per¬ 
form  psychological  operations  functions.  These  stove- 
piped  systems  would  likely  result  in  higher  cost  and 
reduced  interoperability  and  flexibility. 

To  minimize  this  organizational  bias,  operational  model¬ 
ing  should  focus  on  the  functions  and  activities  to  be  per¬ 
formed,  rather  than  on  who  or  what  unit  performs  them. 
This  is  illustrated  in  the  activity  node  tree  shown  in  Fig¬ 
ure  1 .  Once  the  common  processes  are  mapped,  the  truly 
different  activities  stem  from  the  common  ones  and  can 
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Druyun's  home  sale  appears  just  as  she  advertised  it:  a 
mere  coincidence  that  met  all  legal  requirements.  Were 
a  violation  to  exist,  it  would  be  of  1 8  U.S.C.  section  209, 
a  law  prohibiting  supplementation  of  federal  salary  by 
a  nonfederal  entity.  However,  on  the  face  of  the  infor¬ 
mation  provided,  some  questions  were  bound  to  be 
raised,  as  evidenced  by  several  press  articles  including 
one  in  the  Oct.  7,  2003  Wall  Street  Journal  and  another 
in  the  Washington  Post  of  the  following  day. 

To  serve  as  a  comparison,  take  the  house  sale  by  Rep. 
Randy  "Duke"  Cunningham,  R-Calif.,  to  Mitchell  Wade — 
a  clearly  illegal  exchange.  Cunningham  sat  on  the  House 
Defense  Appropriations  Subcommittee.  Wade's  com¬ 
pany,  MZM,  Inc.,  was  in  defense  intelligence  contract 
work.  Wade  purchased  Cunningham's  house  in  No¬ 
vember  2003  for  $1 ,675,000.  Shortly  after  Wade  pur¬ 
chased  the  house,  MZM  began  receiving  multimillion- 
dollar  contracts.  Wade  put  the  former  Cunningham  house 
on  the  market  immediately  after  the  purchase  and  never 
occupied  it.  It  remained  on  the  market  for  seven  months. 
Wade  eventually  sold  it  for  a  loss  of  approximately 
$700,000. 

Key  differences  exist  between  the  two  cases.  The  pur¬ 
chase  price  for  Druyun's  house  was  in  line  with  other 
purchases  in  the  same  neighborhood.  The  fact  that 
Druyun  possessed  the  house  for  a  relatively  short  time 
while  making  a  substantial  gain  is  irrelevant  unless  the 
August  2001  seller  somehow  conspired  with  Boeing  to 
sell  an  artificially  underpriced  home.  There  is  no  evi¬ 
dence  to  support  such  a  conspiracy  theory.  In  addition, 
the  Northern  Virginia  real  estate  market  was  booming 
at  the  time,  and  annual  1 0  percent  increases  in  home 
values  were  the  norm.  Finally,  Judy  occupied  the  house 
he  purchased,  indicating  he  was  buying  it  for  himself. 


\ 

The  inflated  purchase  price  of  Cunningham's  house,  as 
evidenced  by  the  subsequent  sale  at  a  significant  loss, 
was  clearly  a  subterfuge  for  bribery.  Wade's  failure  to 
occupy  the  house  and  his  attempt  to  sell  it  that  same 
month  further  support  the  bribery  charge. 

Although  the  Druyun  sale  met  all  legal  requirements, 
there  is  an  important  point  to  consider.  Individuals  oc¬ 
casionally  find  themselves  in  a  conundrum  between  be¬ 
havior  that  is  legal  for  the  individual  yet  may  not  be  good 
for  the  organization.  This  is  often  referred  to  as  an  ap¬ 
parent  conflict  of  interest.  It  is  easy  to  rationalize  away 
apparent  conflicts  of  interest,  especially  if  the  action  is 
not  a  legal  violation. 

Not  every  individual  action  is  good  for  the  organization. 

In  this  case,  even  if  Druyun  had  not  been  convicted  of 
other  violations,  the  DoD  decision  to  lease  Boeing  tankers 
would  have  been  tainted  by  the  sale  of  her  home,  even 
though  she  had  cleared  it  with  Air  Force  general  coun¬ 
sel.  The  government  does  not  expect  individuals  to  take 
a  monetary  loss,  but  in  light  of  the  Northern  Virginia 
housing  market  at  the  time,  Druyun  could  have  declined 
to  sell  the  house  to  Judy  based  on  the  apparent  conflict 
and  could  still  have  reasonably  expected  to  make  a  fairly 
rapid  sale  at  a  comparable  price  to  another  buyer. 

Individuals  should  guard  against  apparent  conflicts  of 
interest— which  need  not  be  of  the  magnitude  of  a  house 
transaction.  For  example,  do  you  meet  alone  with  a  ven¬ 
dor  at  the  end  of  every  quarter  just  before  a  big  order  is 
placed?  There  may  be  valid  reasons  for  doing  so,  but  the 
natural  inclination  for  someone  observing  the  behavior 
is  to  suspect  that  some  illegal  business  may  be  going 
on.  Instead  of  meeting  alone,  think  about  taking  some¬ 
one  with  you  as  an  observer,  or  use  it  as  a  training  op¬ 
portunity  for  a  less  experienced  employee.  By  increas¬ 
ing  transparency  in  your  individual  activities,  you  may 
reduce  the  apparent  conflict. 


be  depicted  in  the  lower  levels  and  branches  of  the  tree. 
By  keeping  the  focus  on  process,  we  can  better  ensure 
interoperability  and  minimize  the  amount  of  stove-piped 
system  solutions.  Bottom  line:  For  the  process  to  rule  the 
show,  organizational  bias  has  to  go. 

Level-of-War  Bias 

This  bias  stems  from  the  fact  that  the  majority  of  military 
organizations  and  the  systems  that  support  them  are  par¬ 
titioned  into  two  levels:  the  operational  and  the  tactical. 
The  operational  level  focuses  on  what,  where,  when,  and 
how  forces  will  be  organized,  integrated,  and  employed 
to  achieve  strategic  goals.  These  are  higher-order  activi¬ 
ties  that  primarily  guide  and  govern  the  activities  of  the 
tactical  level.  The  tactical  level  focuses  on  lower-level  ac¬ 


tivities,  specifically  the  execution  of  specific  missions.  Or¬ 
ganizations  are  formed  at  this  level  and  usually  report  to 
an  operational  level  headquarters  or  operating  center.  Al¬ 
though  the  levels  are  relatively  easy  to  differentiate  and 
understand,  real  processes  do  not  restrict  themselves  to 
these  human-created  divisions.  As  network  capabilities 
increase  and  organizations  are  pushed  to  transform  into 
more  streamlined  and  flatter  entities,  the  lines  between 
the  tactical  and  operational  levels  blur.  Viewing  processes 
as  a  whole  and  not  restricting  them  to  operational  or  tac¬ 
tical  lanes  only  is  essential  to  becoming  more  effective 
and  is  a  main  aspect  of  many  business  process  reengi¬ 
neering  and  Lean  methodologies.  Architects  need  to  re¬ 
alize  this  and  recognize  when  individuals  speak  and  think 
with  a  level-of-war  bias.  For  example,  talking  to  someone 
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at  a  command  headquarters 
will  often  center  on  operational- 
level  systems  and  processes. 

Talking  with  those  at  the 
squadron  or  company  level  will 
often  result  in  tactical-level  em¬ 
phasis.  But  unlike  these  con¬ 
versations,  operational  and  tac¬ 
tical  processes  do  not  operate 
in  isolation,  and  neither  should 
their  architectures.  The  archi¬ 
tect  must  see  these  biases  and 
seek  the  whole  picture  process 
and  then  pick  the  right  level  of 
abstraction.  Therefore,  to  con¬ 
fine  the  architecture  to  only  one 
level  of  war  can  make  the  ar¬ 
chitecture  poor. 

Hollow  Transfer  Activities 

Using  the  DoDAF,  operational  activities  are  often  mod¬ 
eled  using  integrated  definition  (IDEF)  methods,  specifi¬ 
cally  the  IDEFO  (pronounced  IDEF-zero)  function  model¬ 
ing  method.  IDEF  models  were  originally  developed  for 
process  modeling  involving  physical  production  tasks  such 
as  manufacturing,  in  which  material  assets  (outputs)  are 
produced  using  raw  materials  (inputs)  and  manufactur¬ 
ing  resources,  facilities,  and  manpower  (mechanisms), 
subject  to  the  manufacturing  rules  and  procedures  (con¬ 
trols).  IDEFO  function  modeling  has  since  been  adopted 
for  other  applications  such  as  business  process  modeling 
and  DoDAF. 

When  using  IDEFO  for  DoDAF  activity  modeling,  an  in¬ 
teresting  problem  arises  when  dealing  with  information 
transfer  activities.  Many  functions  within  larger  processes 
involve  activities  that  simply  move  information  or  prod¬ 
ucts  from  one  location  or  node  to  another.  Architects  may 
find  themselves  creating  many  of  the  same  types  of  in¬ 
formation  transfer  activities,  some  inferred  and  some 
specifically  outlined  in  governing  publications.  These  ac¬ 
tivities  are  easily  found  in  terms  such  as  obtain,  receive, 
transmit,  issue,  distribute,  submit,  store,  and  others.  We 
call  these  activities  “hollow”  transfer  activities.  They  are 
hollow  because  they  do  not  contain  a  transformation  func¬ 
tion  that  produces  a  new  and  unique  output.  They  are 
transfer  activities  because  they  simply  move  information 
from  one  location  to  another.  The  information  content  is 
not  changed  or  transformed  in  any  way;  it  is  merely  trans¬ 
ferred  or  made  available  to  support  other  activities  or 
functions. 

The  question  of  how  an  architect  should  show  these  types 
of  activities  within  IDEFO  and  other  modeling  methods 
generates  considerable  debate  in  the  modeling  commu¬ 
nity.  Some  IDEFO  and  other  modeling  purists  would  argue 
that  the  “obtain  information”  activity  should  not  be  shown 


because  it  does  not  show  a 
transformation.  Others  would 
argue  that  the  discussion  is 
somewhat  trivial  or  should  be 
left  to  system  views,  not  oper¬ 
ational  activities.  But  there  is  a 
danger,  depending  on  the  pur¬ 
pose  of  the  architecture,  in  leav¬ 
ing  these  activities  out  of  op¬ 
erational  views. 

For  example,  Figure  2  shows 
two  activity  models  depicting 
the  same  mission-tasking 
process.  A  mission  objective  is 
received,  analyzed,  and  broken 
down  into  one  or  more  mission 
tasks,  which  are  distributed  to 
mission  planners  and  then 
used  as  controls  to  help  create  a  mission  plan.  This  same 
process  could  occur  within  a  single  room  or  in  different 
locations  across  the  world.  The  top  model  in  the  figure 
shows  the  “distribute  task  to  planners”  hollow  transfer 
activity.  The  bottom  model  does  not.  In  the  top  model, 
there  is  no  doubt  that  the  transfer  activity  has  visibility. 
But  again,  it  is  hollow  because  there  is  no  transformation; 
the  output  is  the  same  as  the  control.  The  “mission  task” 
control  is  also  the  “mission  task”  output.  By  showing  the 
hollow  transfer  activity,  it  is  very  clear  that  the  “distrib¬ 
ute  task  to  planners”  activity  must  occur,  and  there  should 
be  a  mechanism  (person  or  technology)  assigned  to  it.  A 
missing  mechanism  could  show  a  gap  in  capabilities,  es¬ 
pecially  since  the  “distribute  task  to  planners”  activity  can 
take  significant  time  and  resources. 

The  bottom  model  does  not  include  the  “distribute  task 
to  planners”  activity.  It  is  more  precise  and  focuses  on 
the  core  activities  that  are  not  distribution  functions.  As 
such,  there  are  no  hollow  transfer  activities  depicted. 
From  this  model,  it  would  be  easy  to  overlook  output  dis¬ 
tribution  activities  and  the  mechanisms  that  execute  them. 
In  simple  terms,  one  could  model  a  process  but  not  see 
its  distribution  pitfalls  and  thus  not  ensure  the  right  in¬ 
formation  gets  to  the  right  people.  If  the  operational  ac¬ 
tivities  do  not  include  the  transfer  activities,  systems  and 
their  functions  may  not  be  appropriately  visible.  Elimi¬ 
nating  hollow  transfer  activities  may  also  not  accurately 
capture  what  could  be  the  most  time-  and  resource-in¬ 
tensive  activities  within  an  enterprise. 

Ultimately,  if  the  purpose  of  the  architecture  includes  en¬ 
suring  the  right  information  or  product  gets  to  the  right 
people  at  the  right  time,  or  mapping  existing  real-world, 
constraint-based  and  location-dependent  processes,  it  is 
essential  that  hollow  transfer  activities  be  represented  in 
some  form.  That  may  mean  altering  existing  modeling 
techniques  or  investigating  new  methods  to  answer  the 


FIGURE  2.  Activity  Diagram  Show¬ 
ing  Hollow  Activity. 
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critical  questions.  How  an  architecting  team  deals  with 
this  can  be  critical,  especially  considering  the  growing 
importance  of  interoperable  and  net-centric  architectures. 
The  failure  to  make  certain  activities  visible  within  an  op¬ 
erational  architecture  can  influence  where  future  invest¬ 
ment  and  existing  resources  are  spent.  Failure  to  model 
transfer  activities  properly  or  make  them  visible  for  analy¬ 
sis  can  inadvertently  further  DoD  interoperability  and  in¬ 
formation-distribution  problems.  Therefore,  it  is  critical 
to  examine  hollow  transfer  activities  to  prevent  distribu¬ 
tion  problems  and  lack  of  interoperability. 

To  Wrap  it  Up 

In  summary,  we  have  proposed  the  following  heuristics 
in  order  to  help  overcome  and  avert  problems  when  de¬ 
veloping  joint  operational  architectures: 

■  Lack  of  knowledge  in  the  domain  equals  architecture 
pain.  A  readily  available  network  of  subject  matter  ex¬ 
perts  makes  the  architecture  relevant. 

■  To  have  a  joint  vocabulary,  use  the  joint  dictionary.  Seek 
a  common  understandable  vocabulary  by  referencing 
joint  standards  and  the  joint  dictionary. 

■  When  defining  a  joint  process  stalls,  there  needs  to  be 
a  process  owner  to  make  firm  calls.  When  establishing 
an  enterprise-wide  operational  architecture,  there  needs 
to  be  one  boss  to  overcome  irreconcilable  differences 
across  stakeholders. 

■  Abstract  too  high— the  models  can  lie;  abstract  too  low — 
one  gets  lost  in  the  flow.  Architect  at  the  level  of  ab¬ 
straction  that  provides  the  answers  sought. 

■  For  the  process  to  rule  the  show,  organizational  bias  has 
to  go.  People  tend  to  think  “organization”  first,  not 
“process,”  and  architecture  models  should  be  created 
independent  of  the  organization. 

■  To  confine  the  architecture  to  only  one  level  of  war  can 
make  the  architecture  poor.  Follow  the  process  and  in¬ 
formation  flows;  do  not  limit  context  to  operational  or 
tactical  level  if  not  a  necessary  constraint. 

■  Critically  examine  hollow  transfer  activities  to  prevent 
distribution  problems  and  lack  of  interoperability.  Be 
critical  of  hollow  transfer  activities  and  ensure  they  have 
the  appropriate  visibility  in  order  to  prevent  and  ad¬ 
dress  capability  gaps. 

As  systems  increase  in  complexity,  the  architect’s  job  will 
continue  to  be  tested.  These  simple  heuristics  can  help 
increase  interoperability  and  the  gains  produced  from  ar¬ 
chitectural  development  in  the  DoD. 


The  authors  welcome  comments  and  questions. 
Contact  them  at  todd.wieser@hurlburt.af.mil, 
gregory . j .  miller@pentagon .  af .  mil ,  aaron .  piepkorn@ 
pentagon .  af .  mil ,  james .  kennedy  @  pentagon .  af .  mil , 
robert.mills@afit.edu,  and  john.colombi@afit.edu. 
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